Unified Messaging Systems (UMS) are communication systems providing a plurality of communication services such as email, SMS, voicemail, answering machine, fax, telephone and the like, wherein UMS allow to catenate the different communication services with each other. So UMS allows e.g. to send a fax to an email address, or to send a SMS or a MMS by email to a mobile phone, or to send an email or a SMS to a telephone, wherein the text of the email or the SMS is converted into speech, e.g. by a text-to-speech (TTS)-converter provided by a server. Furthermore UMS allows a user e.g. to access his emails via mobile phone.
A UMS typically consists of one or more servers and one or more end user devices remotely attached to and remotely controllable by said server. The server provides one or more applications dedicated to the end user device, wherein each application provides at least one communication service to be used via said end user device.
A focus in the development of UMS is to provide a single end user device that allows using all or at least some of the described communication services. Such an end user device typically comprises a terminal similar to a conventional desktop or cordless telephone set with at least a microphone, a loudspeaker and several buttons required to dial a telephone number, wherein to provide the additional communication services such a terminal features e.g. a display such as a small monitor or the like to be used to display emails, SMS, faxes and the like, plus various buttons to be used to control the different communication services.
Thereby the problem arises that with an increasing number of communication services the number of buttons increases significantly, leading besides the poor design to poor usability since with an increasing number of buttons the clearness of the terminal vanishes.
To handle this, up to now the solution is followed to provide audio menus in combination with Automated Speech Recognition (ASR) when the context of a particular communication service is controlled by an appropriate application server. Thereby to deal with various menus and functionalities instead of buttons audio information is provided selectable by the user via voice input or by pressing a specific number on the keyboard. Thereby typically the menu items of a menu are read by a voice wherein the user can choose a menu item by voice input or by pressing a specific number on the keyboard. The disadvantage of such a solution is the immense complexity and costs in providing such features. Furthermore it is very time-consuming to interact with a menu via voice input.
Other solutions to deal with similar problems are known e.g. from scientific pocket calculators, telephone systems and remote controls of TV-Sets. Thereby so-called soft keys are used providing various functionalities depending on the menu actually used. Soft keys comprise either buttons arranged besides a display showing the actual functionality of the particular button, or comprise touch sensitive display areas, e.g. on a touch screen, showing the actual functionality of the particular area. Thereby the functionalities of the soft keys are hard-coded within the particular devices, wherein the software design of the device i.e. the particular functionalities of the soft keys within particular menus are fixed. Such a solution cannot be adapted to new functionalities, user behavior and the like.
Furthermore it is known to use soft keys in telecommunications e.g. to allow a user to individually configure functionalities of a terminal. So it is possible to configure a soft key in a way that it provides e.g. access data required for specific applications or functionalities when pushed by the user.
From GB 2 365 734 A it is known to use soft keys in combination with end user devices such as mobile phones and the like to be used to access source data of Internet web-pages or other mark-up language documents. Thereby functionalities to be assigned to the soft keys are identified within said source data. The identification can be done within the end user devices or it can be done on a source server or on a proxy server that after identification provides the end user device with data comprising the actual functionalities of the soft keys. Such a solution has the drawback of an immense complexity and of only low reliability. Furthermore identifying soft key functionalities from source data is too time-consuming.
From EP 1 496 677 A1 it is known to program soft keys of an end user device by the user himself or by receiving a configuration message automatically installing the soft key functionalities. The configuration message is received by means of infrared data access, Bluetooth, WAP/WEB download, computer based synchronization software or by a SMS or a MMS. After receiving the configuration message, the soft keys are hard-coded within the end user device. Thereby it is not foreseen to change the functionalities of the soft keys with changing communication services and the like. Due to this, such a solution is not suitable in combination with UMS.
Another disadvantage of known soft key solutions is the requirement of storage at the end user device required to store the different functionalities of the soft keys. Storage installed in end user devices is costly and can lead to complaints and callbacks due to damaged storages and hardware failures. Furthermore adapting end user devices providing hard coded soft key functionalities to new features, functionalities or communication services is very costly.
Regarding UMS the main problem remains that the different communication services provided by UMS provide different, possibly changing functionalities that have to be accessible in real-time by the user. The changing in and/or of functionalities can be justified e.g. by introducing new functionalities supported by new, improved or updated software on particular application servers providing particular communication services. So it is thinkable, e.g. in the course of usability improvements, to change functionalities or to change the sequence of functionalities provided by an application server providing a particular communication service, wherein to ensure and not to affect the availability of the UMS the changing preferably takes place in service. Furthermore it is thinkable that some functionalities or the sequence of functionalities depend on user behavior so that they can change according to user behavior. Due to this, it is not useful to hard-code soft key functionalities within an end user device to be used in combination with UMS.